1. Statement of the Technical Field
The present invention relates to the field of business process programming and more particularly to the debugging of a business process program.
2. Description of the Related Art
The business process program paradigm represents a revolutionary approach to wide-scale, distributed data processing. Business process programs utilize a loosely coupled integration model to allow flexible integration of heterogeneous systems in a variety of domains including business-to-consumer, business-to-business and enterprise application integration. Through the use of a messaging protocol, a common grammar for describing business process logic and an infrastructure for publishing and discovering services in a systematic way, business processes can “find” each other and can interact with one another following a loosely coupled, platform-independent model.
Presently, the interaction model of the business process program can be viewed as a stateless model of synchronous or uncorrelated asynchronous interactions. Models for business interactions typically assume sequences of peer-to-peer message exchanges, both synchronous and asynchronous, within stateful, long-running interactions involving two or more parties. Nevertheless, systems integration requires more than the mere ability to conduct simple interactions by using standard protocols. Rather, the full potential of the business process program paradigm as an integration platform can be achieved only when applications and business processes are able to integrate their complex interactions by using a standard process integration model.
Workflow languages fulfill many if not all of the aspects of a standard process integration model. In this regard, typical workflow language specifications define a technology for integrating cross-enterprise business processes. By coordinating stateful interactions of loosely coupled services across enterprise boundaries, the workflow language can provide a means of modeling the interactions between an enterprise and its business partners, suppliers and customers and thus the value chain of the enterprise. Most importantly, a workflow language can define a notation for specifying business process behavior for use in a business process program.
Workflow languages differ from older, more traditional procedural programming languages in that workflow languages concentrate on allowing the applications developer to specify the interactions between existing processing logic in a business process program rather than requiring the developer to design a business process program and its accompanying processing logic from scratch. As a result, in the workflow paradigm, execution environments partition the program instructions into a number of disjoint tasks, often referred to as activities, which can be coupled together through a description of dependencies between the activities, often referred to as links.
Generally, an activity can include program logic which can invoked by a process engine. For example, the program logic can be a locally or remotely invokable program object which can be activated by the process engine. The process engine can determine a sequence for invoking program logic based upon the links specified for different program objects. Consequently, a business process program can be conceptually viewed as a grouping of activities and links which are executed in run-time environment. Notably, unlike conventional procedural program logic, the processing logic or program objects of a business process program need not be invoked in the exact order specified by the developer. Rather, the process engine can remain free to execute program objects in any order so long as the constraints of the relationship links are satisfied.
The clear distinction between the procedural programming paradigm and the workflow programming paradigm can lead to difficulties in performing common debugging tasks known in the procedural programming paradigm. In the conventional, procedural paradigm, the developer can step through the instructions of an application according to the ordered instructions produced by the compiler. Even where threading adds a layer of complexity to the compiled application, the individual threads of execution can be reduced to a series of time sequenced instructions which can be filed through “stepping over” and “tracing into” operations.
In contrast, the notion of a thread of execution has not been applied to the workflow paradigm. In fact, to the extent that the workflow paradigm implicates multiple independently acting business processes executing across different execution environments, the element of time slicing modeled by threads simply does not exist. In the prototypical business process program, a process portion of the program can be passed to the processing engine as an activity. Selected activities can be handled for execution through the operation of a message queue which may or may not take selected activities in the prescribed order. Different activities can be executed in different environments having different capacities and execution capabilities. Consequently, different chunks of work can be performed concurrently in an unpredictable order.